Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@README.md`:
- Around line 86-99: The README still mixes Neon/Postgres setup with leftover
Supabase references; remove or replace all Supabase-specific text (e.g.,
headings and phrases like "Supabase Requirements", "independent of Supabase
client", “instead of using Supabase”, and any Supabase-specific troubleshooting
rows) so the doc consistently instructs Neon/Postgres usage under the existing
"Set Up Your Database" section and its script references (scripts/setup-db.sql,
setup-db-ollama.sql, setup-db-ollama-v2.sql, setup-db-google.sql,
setup-db-memory.sql, setup-db-conversation.sql, scripts/security-rls.sql); also
consolidate duplicate or conflicting sections (notably the areas around the
existing Neon instructions and the later Supabase blocks) into a single coherent
setup and troubleshooting section that only mentions Neon/Postgres and updates
any example commands/environment guidance to use DATABASE_URL and Neon
terminology.

In `@src/tools/memory.ts`:
- Around line 803-805: The inline comment above the branch that checks
storeResults && !isDatabaseConfigured() is outdated (mentions Supabase) — update
it to reference generic Postgres/database configuration; locate the comment near
the isDatabaseConfigured() check in src/tools/memory.ts (the block returning
configError('Database', 'Set DATABASE_URL')) and replace the "Only require
Supabase..." text with something like "Only require Postgres/database when
storing results" or another concise phrase indicating a generic database
requirement.

---

Outside diff comments:
In `@src/tools/insights.ts`:
- Around line 80-83: Replace the legacy single-argument toolError calls that
interpolate schema.error with the structured form toolError(toolName, error,
context?). Specifically, where you currently call toolError(`Insight schema not
initialized: ${schema.error}`) in the three places handling schema checks,
change them to use the tool names 'get_insights', 'discover_connections', and
'dismiss_insight' respectively and pass a new Error(schema.error) as the second
argument (e.g., toolError('get_insights', new Error(schema.error))); keep or add
an optional context object if useful. Ensure you update the three occurrences
that check the schema (the ensureSchema() result handling in the get_insights,
discover_connections, and dismiss_insight flows) to this structured pattern.

---

Nitpick comments:
In `@docs/ENV.md`:
- Around line 15-16: Remove the duplicated DATABASE_URL_UNPOOLED entry by
choosing one authoritative location: either keep the full entry in "Core
variables" and delete the row under "Optional / advanced", or retain the
detailed explanation under "Optional / advanced" and shorten/remove the "Core
variables" row; update the remaining entry for DATABASE_URL_UNPOOLED to include
the intended note about unpooled direct connections for migrations so there is a
single clear source of truth.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/tools/insights.ts`:
- Around line 80-83: The code currently treats ensureSchema() failures as
runtime tool errors by calling toolError('get_insights', ...); instead, surface
these as configuration errors using configError(...) because schema/database
failures are permanent and should not trigger retries; replace calls to
toolError(...) that pass ensureSchema().error (e.g., in the get_insights flow
and the other occurrences around the ensureSchema checks) with
configError('get_insights', new Error(schema.error)) so the caller knows this is
a configuration/setup issue rather than a retryable runtime fault.